Replicated with the command:
% uvx --with=brotlicffi python3.14t

• GitHub Actions: Add Python 3.14t to the testing encode/httpcore#1042
• GitHub Actions: Add Python 3.14 and 3.14t to the testing kevin1024/vcrpy#950

@zmedico @cclauss So this means that Python 3.14t wheels will need to be built from source if we want to publish wheels that support more than one Python version?

@zmedico @cclauss So this means that Python 3.14t wheels will need to be built from source if we want to publish wheels that support more than one Python version?

Correct, and this will be the case until a new stable ABI is available to target. A PEP is needed in order to create the new stable ABI, and there's some initial discussion about it here:

https://discuss.python.org/t/making-pyobject-opaque-in-the-limited-api/77206

Please rebase now the #205 has been merged.

• Modernize ci #205

@sethmlarson Can you please approve the GitHub Actions workflow below so we can see if the tests pass?

Hi all, I was planning to work on this, along with updating all the release automation to support building cp314t wheels (if that's ok with @sethmlarson).

IMO it's probably not a good idea to merge this without at least adding a cp314t testing job.

IMO it's probably not a good idea to merge this without at least adding a cp314t testing job.

The double negatives make that line a bit confusing. I believe that you intend to say:

IMO it's a good idea to add a cp314t testing job before merging this.

Should rebase to pick up the Py3.13 and 3.14 tests landed in:

• test on 3.13 #198

Oh... https://www.githubstatus.com

IMO it's a good idea to add a cp314t testing job before merging this.

Yup, that's what I meant.

Please add the change in #210 to this pull request.

• Add free-threaded Python 3.14t to the testing #210

@ngoldbaum Is this the correct way to handle this situation for free-threading? Wouldn't another option be to disable the limited API altogether if free-threading was enabled? You would know better than I, probably.

We want to be testing free-threading (this PR) before declaring the code to be compatible.

My bet is that we will want to be running pytest-run-parallel after this PR lands.

@cclauss @ngoldbaum Is there value in getting a 1.2.0.0 release out ahead of adding support for free-threading? We can release a 1.2.0.1 that adds support for free-threading at any point.

Hi, sorry I haven't looked at anything over here yet.

I'm hoping to carve some time out today but otherwise I should have time later this week.

Please don't feel like cp314t support is necessary to do a release. As you said, that can come in a bugfix release.

@cclauss Is merging this PR confirming that this is the right way to handle this? See: #206 (comment) I was expecting maybe a reference or a link to another project in this same scenario as us.

Current state: We are running tests against python3.14t on every code change. We are not saying that the code is compatible with free-threading. We are merely saying that our current tests pass on free-threaded Python.

We can now add more tests to help us be more confident in free-threading compatibility. As we progress, automated tests will tell us if things break with and without the GIL. nltk/nltk is a project that is in a similar state.

@cclauss in the future I'd appreciate it if you could wait for me to review code. Particularly when I indicate that I want to look at stuff but don't have time.

Yeah my initial thought now that this is merged is that we should maybe... revert it until we get a review from @ngoldbaum? I want to make absolutely sure our build config is correct, because anything we do others are liable to copy, too, if this is not well-trodden ground.

I thought @zmedico's description in the commit message was convincing. Given that this change only affects free-threaded builds (which we do not yet support) I do not see how this change has any effect.

So saying we don't support something doesn't mean that people won't use or try it :) I would actually prefer things keep on breaking until we have a solution we're happy with and are convinced its correct.

I would also prefer backing it out.

You could take a look at the PR where we enable cp314t wheel builds in pynacl, as an example: pyca/pynacl#880

It looks like over there the py_limited_api setting is passed in via pip. I'm not sure what setting py_limited_api to cp314t does. It may work. I'd rather just not set it on the free-threaded build, I think that's clearer. The default in cffi is to build version-specific wheels.

I'd like to do a pass over the wheel-building configuration in this repository to hopefully make it as painless as possible to ship version-specific wheels on the free-threaded build.

@cclauss please please give me some time to look at things and work on things. I will be looking at shipping cp314t wheels, it's just not an emergency and it's ok if it takes a little while to get done. Now that you and I can trigger builds it will be much quicker. You can also rely on my experience here instead of trying to figure out everything on your own.

I also think @sethmlarson would prefer if we hold off on the free-threaded stuff until after v1.2.0 ships.